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Abstract: The NETCONF configuration protocol of the IETF Network Work- 
ing Group provides mechanisms to manipulate the configuration of network 
devices. YANG is the language currently under consideration within the IETF 
to specify the data models to be used in NETCONF . This report describes the 
design and development of a syntax and semantics parser for YANG in java. 
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jYang : un analyseur yang en java 



Resume : Dans le contexte du groupe de travail administration et operation 
des reseaux de 1'IETF, le protocole de configuration NETCONF a ete developpe 
pour manipulcr la configuration d'equipement reseau. YANG est le langage en 
cours de standardisation dans ce groupe. II permet de specifier des modeles de 
donnees utilisable dans l'approche NETCONF. Ce rapport decrit la conception 
et la realisation en java d'un analyseur syntaxique et semantique de specifications 
YANG. 

Mots-cles : parser, java, yang, netconf 
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1 Introduction 

It is common in the network management world that a protocol and a data 
model are separated even if jointly designed, as it was already the case in the 
SNMP[3] protocol and its SMI7; data modeling,COPS[4] and SPPI0, or SMI- 
ng[S] (GDMO and CMIS or WBEM and CIM outside the IETF scope). 

NETCONF is the IETF standard that emerged from the netconf working 
group to configure network devices. The netmod3 working group defines YANG 
as a candidate language to specify data models of values carried by NETCONF. 
This report describes a YANG parser called jYang that provides a syntaxic and 
semantic validation of YANG specifications (called modules or sub-modules). 

This report first provides a short description of NETCONF where some parts 
are referenced by YANG. Section [3] details the YANG language concepts and 
section [5] details the design and implementation of the jYang parser. 

2 NETCONF protocol 

NETCONF is a client/server protocol where the server is a network device 
and the client a management framework that runs management applications. 
Protocol requests and responses focus on configuration manipulation such as 
getting the current configuration, update, create or delete all or some part of it. 
Configurations are represented in an XML document that contains two sort of 
data: 

• configuration data that is writable and that describes configuration pa- 
rameters of the NETCONF agent. 

• state data that is read-only and that describes operational data such as 
counter or statistics. 

A NETCONF agent can have several configurations each one containing 
several configuration data. There can be only one active configuration, called 
the running configuration, at the same time. Other configurations, called 
candidate configurations, can exist without interfering with the running one. 
A special commit capability (cf section I2.4[) asks the agent to pass a candidate 
configuration as the running one. 

Figure Q] extracted from [5] shows the layered protocol architecture of NET- 
CONF. The protocol mainly defines operations and how they are carried by rpc 
mechanisms. 

2.1 Transport protocol 

NETCONF can use several connection-oriented transport protocols. It requires 
that a persistent connection is maintained between peers during a potentialy 
long term session. Ressources reservation can be granted for the session and 
any reserved ressources are released at the end of the connection. 

Authentication, integrity and confidentiality must be provided by the trans- 
port protocol. A NETCONF implementation must support the SSH transport 
protocol mapping. 

ihttp: / /www. ietf.org/html.charters/netmod-charter. html 
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Content (configuration data) 



Operation (<get-config>, <edit-config> ...) 



RPC (<rpc>, <rpc-reply>) 



Transport Protocol (Beep SSH,...) 



Figure 1: NETCONF protocol layers 

The specification language described in this report is not bound to the trans- 
port protocol used with NETCONF. 

2.2 RPC 

The Remote Procedure Call on wich the NETCONF operations are built is 
described by two XML [2] elements : <rpc> for requests and <rpc-reply> for 
responses. The latter can contain a <rpc-error> element when an error occurs 
during the process of a request inside the NETCONF agent. 

2.3 Operations 

Basic operations arc defined as XML elements : 

• <get> : to retrieve all or part of the running configuration and state data; 

• <get-conf ig> : to retrieve all or part of a running or candidate configu- 
ration data; 

• <edit-conf ig> : to load all or part of a configuration data to a specified 
target running or candidate configuration; 

• <copy-conf ig> : to copy existing configuration data in place of a specified 
target running or candidate configuration; 

• <delete-conf ig> : to delete a candidate configuration ; 

• <lock> : to lock the running configuration against any edit or copy config 
operations originated from another session or external access (like SNMP); 

• <unlock> : to unlock a locked configuration; 

• <close-session> : to stop the NETCONG session accepting any request 
but complete operation in progress; 
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• <kill-session> : to stop the NETCONF session without completing any 
operation in progress. 

All operations are in carried <rpc> elements. A common element of get, edit 
and delete operations is a filter element (<f ilter>) that allows some filtering 
on data by using the hierarchical structure of XML documents. 

2.4 Capabilities 

Accepted operations (basic and news operations) and data are defined by ca- 
pabilities. A NETCONF agent can provide more than one capabilities and an 
unique URI references each capabilities. Capabilities are exchanged between 
entities at session establishment time. 

3 YANG 

The YANG Internet-Draft pQ defines YANG as a data modeling language used 
to describe NETCONF configuration and state data. The NETCONF standard 
does not define such a language for its content layer (cf figH]). The netmod 
working group charteJl explains why a more hight level language than XML is 
needed (an old draft can be seen at : http://www.yang-central.org/twiki/pub/- 
Main/YangDocuments/draft-lengyel- why-yang-OO.txt). 

3.1 YANG specifications 

A YANG specification contains formal definitions of data types that will model 
real data maintained by NETCONF agents. Formal definitions follow the YANG 
syntax. YANG provides constructs that give semantics to XML data. As an 
XML document is a collection of imbricated markups, YANG defines statements 
that can be mapped on pattern of markups. Moreover YANG allows reusability 
of specifications with generic statements or augmentation/extension statements. 

YANG specifications are organized in modules and submodules that contain 
data type definitions and operation descriptions. 

3.2 YANG module and submodule headers 

YANG modules and submodules have some headers that are informations re- 
lated to the module or submodule itself. 

3.2.1 Module header 

A module has mandatory headers and one optional header. The mandatory 
ones are the name space and prefix. For example : 

1 module router { 

2 namespace ' ' urn : madynes : xml : ns : yang : router ' ' ; 

3 prefix router ; 

4 ... 

2 http: / /www. ietf.org/html.charters/netmod-charter. html 
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The name space at line [5] is for all data denned in the module and the prefix 
at line 03 can be used inside the module (when confusion is possible) to refer 
some data. A YANG version header is optional. 

3.2.2 Submodule header 

A submodule has one or two headers. It must have a belongs to statement 
and may have the YANG version statement. A submodule belongs to one and 
only one module. For example : 

submodule routing — policies { 
belongs— to router ; 



The submodule routing-policies belongs to the router module at lineO 

3.2.3 Yang specification meta statements 

Meta statements give some general information on the module or submodule. 
These informations concern the organization that defines the module, the con- 
tact, the description and the reference of the YANG specification. At most four 
meta statements can be made. A meta statement of a specification must not be 
duplicated (e.g. two contact meta statement in a module). 

3.2.4 Yang linkage statements 

A yang specification can have import and include statements. 

Import statement The syntax allows to identify another module and asso- 
ciate it to a prefix. For example : 

module router { 

import yang— types { 
prefix yang; 

} 

The module yang-types is imported at line [3] so that any type or data 
defined in this module can be used in the router module. In order to use them 
without conflict, the prefix yang defined at lined] must be used. For example 
(again in the router module): 

leaf network { 

type yang : counter32 ; 

} 

where counter32 is defined in the yang-types module. The prefix used 
must be the same than the one defined in the prefix statement of the imported 
module (see section 15". 2. 1|) . 
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There can be several import statements but each prefix must be unique in 
the module. The prefix defined in a module can be used in this module. A 
submodule can import modules but no submodules. 

Include statement The syntax allows to refer to a submodule. For example: 

1 module router { 

2 ... 

3 include routing — policies ; 

4 ... 

The router module includes the routing-policies submodule at line[3]so 
any type or data defined in the submodule can be used in that router module. 

An included submodule must have a belongs-to statement with the refer- 
ence of the including module (see section 13. 2. 2|l . A submodule can include other 
submodules but they must all belong to the same module. 

3.2.5 Yang revision statement 

Any yang specification should contain revision statements. There is one YANG_Re- 
vision instance for each yang revision statement and each one can contain none 
or one description statement. 

YANG specifications describel data as a tree of nodes. There are two main 
node types; leaf nodes that contain data values and construct nodes that 
contain (in the hierarchical meaning) other nodes. 

3.3 Leaf nodes 

There are two classes of leaf nodes : 

• (leaf) that contains one value; 

• (leaf-list) that contains a list of values of the same type. 

3.4 Construct nodes 

A construct node definition contains other node definitions. Value of such a 
node depends on the type of the construct node: 

• container that contains other nodes and its value is composed of values 
of all contained nodes; 

• list that contains other nodes and its value is composed of several values 
of all contained nodes. A list value can be seen as a two dimensional array 
and a key parameter of the list allows the reference of one instance of 
the list of node (an entry); 

• choice that defines case constructs containing other nodes and its value 
is the value of contained nodes of one of the defined cases; 

• rpc that contains other nodes and is used in the rpc mechanism of NET- 
CONFand its value is the value of contained nodes. 



RT n° 0123456789 



8 



E. Nataf, O. Festor 



• notification that contains other nodes and is used by NETCONF noti- 
fications and its value is the value of contained nodes. 

Following is an example of a part of a YANG specification^] that describes 
a table of network interfaces, a conceptual view of two entries and the XML 
document of this configuration: 



list interfaces { 
key index; 
leaf index { 
type int8; 

> 

leaf name { 
type string; 

> 

leaf type { 
type string; 

} 

leaf speed { 
type int64; 

} 

} 




<list> 
<index> 
1 

</index> 
<name> 

loopback 
</name> 
<type> 

sof tware-loopback 
</type> 
<speed> 

100000000 
</speed> 
<index> 

2 

</index> 
<name> 

ethernet 
</name> 
<type> 

ethernet-csmacd 
</type> 
<speed> 

100000000 
</speed> 
</list> 



3.5 Typedef 

YANG defines a set of base types (integer, float, string. . . ) and allows the 
definition of new types from existing ones by a typedef construct. For example 
below is the definition of a 32 bits counter from the basic unsigned integer 
uint32. 

typedef counter32 { 
type uint32 ; 
description 

"The counter32 type represents... 
reference 



} 



"RFC 2578 (STD 58)"; 



New types can be used in data nodes and in other typedef. Depending on 
the base type used in a typedef, some restrictions can be added like a range 
restriction on numerical values or as a string pattern on string derived types. 
When defining a new type, restrictions must only restrict the value set of the 
base type. The new type is a sub-type of the base type. 



3 All example in this report are inspired from the draft 1 
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3.6 Grouping and Uses 

YANG provides a reusability concept with grouping and uses statements. A 
grouping is a set of definitions (leafs and construct nodes, typedef, grouping. . . ) 
that can be used in other definitions with the uses statement. For example 
below is the definition of the grouping address with two leaf nodes at lines [5] 
and and its usage in the http-container container (line llOp . 

1 grouping address { 

2 leaf ip { 

3 type bits (32); 

} 

5 leaf port { 

e type uint32 ; 

} 

« } 

This construct is equivalent to 

i 

2 container lit tp — server { 

3 leaf name { 

4 type string; 

■ } 

e leaf ip { 
7 type bits (32); 

• I 

9 leaf port { 

10 type uint32 ; 

« } 
» } 



10 container http — server { 

11 leaf name { 

12 type string ; 

13 } 

14 uses address; 

15 } 



3.7 Augmenting 

The augment statement contains nodes and is used to add theses nodes to an 
existing construct node. In the specification below, a container named login at 
lined] contains a leaf named message line [3] and a list user line E] having several 
leaf nodes (just name is shown). The augment statement at line 1131 refers to the 
list user under the container login and adds to it the leaf uid at line 1141 



container login { 
leaf message { 
type string ; 
} 

list user { 
key ' ' name ' ' ; 
leaf name { 
type string 

} 



13 augment login /user { 

14 leaf uid { 

15 type uint 1 6 ; 

10 } 
IT } 



} 
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Note that augmenting is not the same as grouping. Grouping is used to 
reduce the size of a specification by using several times the same construct 
while augmenting allows to add nodes to an existing one. Augmenting is useful 
when an equimement has vendor-specific parameters added to standard ones. 

3.8 Rpc 

As a NETCONF agent can provide capabilities with new rpc embeded oper- 
ations, YANG allows the specification of such an operation. For example the 
activate-sof tware operation below defines data sended in a <rpc> message 
with input statement (line [2]) and data returned in a <rpc-reply> with the 
ouput statement (line [7]). 

rpc activate —software— image { 
input { 

leaf image— name { 
type string ; 

} 

} 

output { 

leaf status { 
type string ; 

} 

} 

} 

3.9 Notification 

A NETCONF agent can send notifications that can be specified with YANG by 
the notification statement. Nodes contained in a specification statement 
model data sent by the agent. Below is an example where the index of a failed 
interface (line \S§ will be sent. 

notification link — failure { 

description "A link failure has been detected"; 
leaf if— index { 

type int32 { range "1 .. max"; } 

} 

} 

3.10 Extensions 

YANG allows the definition of new statements when specific processes requires 
it. The content of an extention is to be interpreted by specific implementation. 
Extensions can be used anywhere in YANG specifications. In the example below, 
the extension c-def ine is specified and used with one name argument (line [6]). 
Each use of an extension must be prefixed by the module prefix where the 
extension is defined. 

extension c— define { 
description 
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"Takes as argument a name string. 
Makes the code generator use the given name in t 
#define ." ; 
argument "name"; 

} 

myext : c- d e f i n e " MYJDNTTERFACES " ; 
3.11 YIN 

YIN is an alternative XML-based syntax for YANG specifications. YIN spec- 
ifications can be generated from YANG ones and are equivalent. The goal of 
YIN specifications is to enable seemless interactions with XML based tools (as 
XSLT). jYang parser allows the generation of YIN specifications from YANG. 

4 jYang 

jYang is a java parser for YANG specifications and an application programming 
interface offering a programmatic access in java to YANG specifications. 

4.1 YANG Parser 

The java parser is built with JJTree and JavaCC but no external library is 
needed to use it. 

• lexical and syntax checks are conformant to the ABNF grammar given in 

• semantical check covers following features : 

— name scoping and accessibility for typedef, grouping, extension, uses, 
leaf and leaflist, inside a module or submodule and with imported and 
included specifications. 

— type restriction for any type (integer, boolean, bits, float,. . . ) and 
typedef 

— default value and restriction 

— augment existing node 

— Xpath for schema node in augment, leaf (of key ref type) and list (for 
unique statement) 

4.2 Repository 

jYang is an open source distribution of our toolkit under the GPL licence. The 
official repository is at the INRIA Gforge web site : 

http: //jyang. gforge. inria.fr 

4 https: / /javacc. dev.java.net 
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4.3 jYang tools 
4.3.1 jYang parser use 

jYang is distributed as a java jar file called jyang. jar and configured to be 
executable. The synoptic is : 

java -jar jyang. jar [-h] [-f format] [-o outputfile] [-p paths] file [file]* 

• -h print the synoptic 

• -f format specifies the format for a translated output (yin format for 
example) 

• -o outputfile the name of the translated output (standard output if not 
given) ignored if no format are given 

• -p paths a path where to find other YANG specifications. It is needed 
if import or include statements are in the checked specification or if the 
environement variable YANG_PATH is not set. 

• file [file]* specifies files containing YANG specification. It must be 
one specification (module or submodule for each file). 

Errors Errors in YANG specifications are printed on the standard error out- 
put. jYang stops checking at the first lexical or syntaxical error but tring to 
check after a first semantical error is encountered. When such an error is de- 
tected, the current bloc statement is escaped and jYang passes to the next 
statement. 



4.3.2 Programmatic access 

jYang provides java classes and interfaces to parse YANG specification inside 
a java program. Internal representation of those specifications can be accessed 
throught the API defined in the section [5] Below is an example of how to parse 
a YANG specification. 

import java . io . * ; 
import jyang . * ; 

public class JyangTest { 

/** 

* Simple jyang test , parses and checks one YANG specification. 

* Imported or included modules or submodules are looked in the 

* current directory. 

* Error messages are on the standard output 
* 

* @param args YANG file name 
*/ 

public static void main( String [] args) throws Exception { 

FilelnputStream yangfile = new FilelnputStream ( args [ ] ) ; 
new yang ( yangfile ) ; 
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YANG.Specification spec = yang . Start () ; 
spec . check ( ) ; 

} 

} 

The program first gets the YANG specification file at line \TE\ A new jyang 
parser is created line \TE\ with this file. The lexical and syntactic check are 
processed at line IT71 and return a YANG_specification object instance that can 
be semantically checked, as at line [18] 

5 jYang API 

5.1 UML class diagram 

Following sections contain the UML class diagrams of the jYang API. UML 
classes (abstacts or not) are java classes and UML interfaces are java interfaces. 
Inheritance relations are directly mapped to the java inheritance mechanism 
(we have limited in the design multiple inheritance to interfaces only). 
For relationships other than inheritance the API follows theses rules : 

• when the cardinality is 0-1 there is a getter and a setter method with 
the name of the related class in the other related class. For example in 
figure [3] there is a method called getArgument in the YANG_Extension 
java class and this method returns an instance of the YANG_Argument java 
class. Such method returns null if there is no related instance (but some 
relations have no lower bound and so must not return null). There is 
also a method called set Argument (YANG_Argument) . 

• when the cardinality is 0-n the getter returns a java Vector instance con- 
taining related instances. The getter has an extra V, for example in the 
figure[2]there is a method called getLinkages () in the YANG_Specif ication 
java class. If there is no related instance, the method returns an empty 
java Vector. For the setter, as it is often used during parsing, there is a 
method called addCJass-JVame (for example addLinkage (YANG_Linkage). 

5.2 YANG specifications 

Figure [U shows the top level classes and interfaces hierarchy. On top is the 
YANG_Specification interface that can be a YANG_Module for a yang module 
or a YANG_SubModule for a YANG submodule. 

5.3 Yang body statements 

Data definitions are in body statements that can be: extension, type definition, 
grouping, data definition, rpc or notification. The YANG_Body interface is the 
common interface for all bodies in a yang specification. 
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YANG_Specification 



YANG Module 



YANGSubModule 



YANG_Header 



"5" 



YANG_Meta 



Y A N G _ N a m e S p a c e . _ I - Y A N G _ B e I o n g Y A N G _ O r g a n i z a t i o n . _'_ Y A N G _ R e f e r e n c e 



YANG_YangVersion 



YANG Prefix 



\— YANG_Linkage <]- 



YANG Contact. 



YANG Description 



YANG_lmport 



YANG_lnclude 



YANG Revision 



YANG Extension 



YANG_Grouping 



YANG_Rpc 



YANG_Body 



YANG_TypeDef 



YANG_DataDef Y A N G _ N o t i f i c a t i o n 



Figure 2: Module and SubModulc 
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5.4 Bodies 

5.4.1 Extension statement 

An extension statement (fig. [3]) can be stand alone or can contain other state- 
ments either as argument, status, description and reference. Each of these 
statements can occur at most once. Their description is detailed in section f5. 51 

YANG_Extension 



YANG_Argument 



YANG_Description 



YANG Status 



YANG Reference 



Figure 3: Extension statement classes 



5.4.2 TypeDef statement 

A typedef statement (fig. [4|) must contain a type statement and can contain 
units, default, status, description and reference statements. Each of these state- 
ments can occur at most once. Their description is detailed in section [5.61 



YANG_TypeDef 



YANG Status 






YANG Type 











YANG Description 






YANG Unit 















YANG Reference 






YANG Default 













Figure 4: TypeDef statement classes 



5.4.3 Grouping statement 

A grouping statement (fig. [5J can be single or can contain status, description 
and reference statements. Each of these statements can occur at most one 
time. A grouping statement can also contain several other grouping, typedef 
and datadef statements. Their description is detailed in section f5. 71 
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— YANG_Grouping 



YANG Status 



YANG_Description 



YANG Reference 



- n 


YANG TypeDef 


- n 






YANG DataDef 







Figure 5: Grouping statement classes 



5.4.4 DataDef statement 



A datadef statement (fig. is either a leaf, leaflist, list, choice, anyxml, uses 
or augment statement. Their description is detailed in section [ 



YANG_DataDef 



YANG Container I YANG Choic 



YANG Leaf 



YANG Leaf List 



YANG_List I .YANG_Augment 



YANG_AnyXml 



YANG Uses 



Figure 6: DataDef statement classes 



5.4.5 Rpc statement 

A rpc statement (fig. [7]) can be alone or can contain status, description, ref- 
erence, input and output statements. Each of these statements can occur at 
most once. A rpc statement can also contain several other grouping, typedef 
and datadef statements. 

5.4.6 Notification statement 

A notification statement (fig. [5]) can be alone or can contain status, description 
and reference statements. Each of these statements can occur at most once. 
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YANG_Rpc 



YANG Status 





YANG Grouping 











0-1 




YANG TypeDef 


YANG Description 















YANG Reference 









YANG_lnput 





YANG Output 







Figure 7: Rpc statement classes 



A notification statement can also contain several other grouping, typedef and 
datadef statements. 



YANG_Notification 



YANG Status 






YANG Grouping 











YANG Description 


u - 1 


- n 


YANG TypeDef 











YANG Reference 






YANG DataDef 













Figure 8: Notification statement classes 



5.5 Extension details 

This section refers to the section l5.4.1l It details all statements that can occur 
in an extension statement. 

5.5.1 Argument statement 

An argument (fig. E]) is composed of at most one yin statement. A yin statement 
contains either the "true" or the "false" string. 

There is no more syntax checking needed by other extension substatements 
(description, status and reference). 
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YANG_Argument 



Y A N G _ Y i n 



Figure 9: Argument statement classes 



5.6 Typedef detail 

This section refers to the section 15.4.21 It details all statements that can occur 
in a typedef statement. 



5.6.1 Type statement 

A type (fig. I10p is composed of cither one or more cnum statement or only one 
of the specification or restriction statement. 

YANG_Type 



YANG Enum 




0-1 


YANG NumericalRestriction 















YANG UnionSpecification 






YANG KeyRefSpecification 











YANG String Restriction 






YANG B i t S p e c i f i c a t i o n 









Figure 10: Type statement classes 



There is no more syntax checking needed by other typedef substatements 
(description, status, default and units). Default and units statements are subject 
to semantical checking. 



5.7 Grouping detail 

This section refers to the section 15.4.31 It does not detail any statement like 
status, description and reference. Typedef is detailed in the section 15.61 The 
data-def statements are detailed in the section [S~B1 



5.8 Data def details 

This section refers to the section 15.4.41 It details those statements that can be 
a data-def statement. 
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5.8.1 Container statement 

A container statement (fig. Illj) can contain several must, typedef, grouping 
and data-def statements. Presence, config, status, description and reference 
statements are optional. 

YANG_Container 



YANG Must 






YANG TypeDef 











YANG Presence 






YANG Body 











YANG Config 






YANG DataDef 















YANG Status 






YANG Reference 















YANG Description 









Figure 11: Container statement classes 



5.8.2 Leaf statement 



A leaf statement (fig. fT2T) must contain one type statement (see section [5. 6. 1|) 
and several must statements. Units, default, config, mandatory, status, reference 
and description are optional. 



YANG Leaf 



YANG_Type 



YANG Units 



YANG Must 



YANG Default 



YANG_Config 



YANG_Mandatory 



YANG_Status 



YANG_Reference 



YANG_Description 



Figure 12: Leaf statement classes 
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5.8.3 Leaf List statement 

A leaf-list statement (fig. f]~3|) must contain one type statement (see sec- 
tion several must statements. Units, default, config, min element, max 
element, mandatory, status, reference and description are optional. 



YANG_Leafl_ist 



YANG Type 






YANG MinElement 















YANG Units 


0-1 


U - 1 


YANG MaxElement 















YANG Must 






YANG OrderedBy 











YANG Config 


0-1 


0-1 


YANG Status 











YANG Description 






YANG Reference 









Figure 13: Leaf list statement classes 



5.8.4 List statement 

A list statement (fig. fT4"j) can contain several must, unique, typedef and group- 
ing statements and must contain at least one data-def statement. Key, min el- 
ement, max element, ordered-by, status, description and reference are optional. 



5.8.5 Choice statement 

A choice statement (fig. [TB|) can contain several short-case or case statements 
that are detailed in section 15.91 Default, mandatory, status, description and 
reference are optional. 

5.8.6 Any-xml statement 

An any-xml statement (fig. I16j) can contain a config, mandatory, status, des- 
crition and reference statements. 



5.8.7 Uses statement 

An uses statement (fig. I17p can contain a status, description, reference and 
refinement statements. The refinement is detailed in section [5.101 
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YANG_List 



YANG_Must 



YANG Key 




0-1 


YANG Description 











YANG Unique 






YANG Reference 











YANG MinElement 






YANG Grouping 











YANG MaxElement 






YANG DataDef 















YANG_Status 



YANG Config 






YANG TypeDef 











YANG Ordered 









Figure 14: List statement classes 



YANG_Choice 



YANG Default 


- 1 


0-1 


YANG Status 











YANG Mandatory 


0-1 


o-i 


YANG Description 











YANG ShortCase 


- n 


0-1 


YANG Reference 















YANG Case 











Figure 15: Choice statement classes 
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YANG_AnyXml 







0-1 


0-1 






YANG Config 


YANG_Description 


















0-1 


0-1 






YANG Mandatory 






YANG Reference 




0-1 
















YANG Status 









Figure 16: Any-xml statement classes 



YANG_Uses 



YANG Status 


0-1 


0-1 


YANG Description 















YANG Refinement 






YANG Reference 













Figure 17: Uses statement classes 



5.8.8 Augment statement 

An augment statement (fig. I18[) can contain at least one datadef or case state- 
ments or one input or output statements. It depends on the augmented node. 
When, status, description and reference statements are optional. 



YANG_Augment 



YANG When 















YANG_Description 



YANG Status 






YANG Reference 











YANG Input 






YANG DataDef 











YANG Output 






YANG Case 









Figure 18: Augment statement classes 
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5.9 Case and Short Case statements 

Case and short case use are described in section 15.8.51 

5.9.1 Case statement 

A case statement (fig. [T9"f can contain several case-data-def statements. Status, 
description and reference are optional. Case-data-def is detailed in section lF.9.31 



YANG_Case 



YANG Status 






YANG Description 











YANG C a s e D e f 






YANG Reference 













Figure 19: Case statement classes 



5.9.2 Short Case statement 

A short case statement (fig. [2H|) can be either a container, leaf, leaf-list, list or 
any-xml statements. 



YANG_ShortCase 



YANG_Container . i YANG List 



YANG Leaf 



YANG_AnyXml 



YANG_LeafList 



Figure 20: Short Case statement classes 



5.9.3 Case Data Def statement 

A case data def statement (fig. l2"Tj) can be either a container, a leaf, a leaf-list, 
a list, an any-xml, an uses or an augment statements. Case data def use is 
described in section [5. 9. 11 
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YANG_CaseDataDef 



YANG_Container 




YANG_AnyXml 

















YANG_Leaf 


1 . 


YANG_Uses 














YANG_LeafList 


YANG_Augment 







Y A N G _ L i s t 



Figure 21: Case Data Def statement classes 



5.10 Refinement statement 

The refinement statement (fig. [2"2"j) can be a refinement of a container, leaf, 
leaf- list, choice or any-xml statement. Refinement use is described in section 

YANG_Refinement 



YANG RefineContainer 






YANG RefineChoice 















YANG RefineLeaf 






YANG RefineAnyXml 















YANG RefineLeaf List 






YANG RefineList 













Figure 22: Refinement statement classes 



5.10.1 Refined Container statement 

A refined container statement (fig. I23[) can contain several must and refinement 
statements. Presence, config, description and reference are optional. 



5.10.2 Refined Leaf statement 

A refined leaf statement (fig. |24|) can contain several must statements. Default, 
config, description and reference are optional. 
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VANG RefineContainer 



YANG_MuSt 



YANG Presence 



YANG_Config 



YANG_Description 



YANG Reference 



YANG_Refinement 



Figure 23: Refine Container statement classes 



YANG RefineLeaf 



YANG MuSt 



YANG Default 



YANG_Config 



YANG_Mandatory 



YANG_Description 



YANG Reference 



Figure 24: Refine Leaf statement classes 
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5.10.3 Refined Leaf List statement 

A refined leaf-list statement (fig. I25j) can contain several must statements. 
Config, min-element, max-element, description and reference are optional. 

YANG_RefineLeafList 



YANG Must 



YANG_Config 



YANG M i n E I e m e n t 



YANG MaxElement 



YANG Description 






YANG Reference 









Figure 25: Refine Leaf List statement classes 



5.10.4 Refined List statement 

A refined list statement (fig. |27)|) ) can contain several must and refinement 
statements. Config, min-element, max-element, description and reference are 
optional. 



YANG_RefineList 



YANG Must 






YANG MinElement 















YANG Config 






YANG MaxElement 















YANG Description 






YANG Reference 













YANG Refinement 









Figure 26: Refine List statement classes 



5.10.5 Refined Choice statement 

A refined case statement (fig. |2"T|) can contain several refine case statements. 
Default, mandatory, description and reference are optional. 
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YANG_RefineChoice 



YANG_Default 



YANG Mandatory 


0-1 


0-1 


YANG Reference 











YANG_Description 



YANG RefineCase 











Figure 27: Refine Choice statement classes 



5.10.6 Refined Any-xml statement 

A refined any-xml statement (fig. I28j) optionaly contains a config, mandatory, 
description and reference statements. 

YANG_RefineAnyXml 



YANG Config 






YANG Description 











YANG Mandatory 






YANG Reference 









Figure 28: Refine Any-xml statement classes 



5.11 Global view 

The figure I2U1 shows all classes and their inheritance relationships. 

6 Conclusions and future work 

This report describes the jYangparser and its API. The work is based on an 
early release of the draft pQ. futhur revisions will follow the YANG evolution. 

jYang allows a static parsing of YANG specifications but there are several 
other checks that need to be done at the execution time. We plan to define 
some mechanisms to ensure that a NETCONF agent realizes such checks. The 
list below may be not exhaustive but draws our main goals : 

• YANG specifications can use an object-instance data type that refers 
to an existing element in a configuration. A NETCONF agent must verify 
that the refered element effectively exists, or has a default value. 
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• YANG specifications can define new operations and notifications. A NET- 
CONF agent must provide them on top of the RPC mechanism. 

These evolutions will be bound to a particular NETCONF implementation. 
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